home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-97 < prev    next >
Text File  |  1988-12-01  |  38KB  |  1,398 lines
  1.  
  2. IEN: 97
  3.  
  4.  
  5.  
  6.  
  7.  
  8.                    FLEXIBLE DATAGRAM PROTOCOL
  9.  
  10.  
  11.                             Version 1
  12.  
  13.  
  14.  
  15.                            April 1979
  16.  
  17.  
  18.  
  19.                           prepared for
  20.  
  21.                   Defense Communication Agency
  22.                      WWMCCS ADP Directorate
  23.               Command and Control Technical Center
  24.                     11440 Isaac Newton Square
  25.                         Reston, Va. 22090
  26.  
  27.  
  28.  
  29.  
  30.                                by
  31.  
  32.                         MITRE Corporation
  33.                    1820 Dolley Madision Blvd.
  34.                         McLean Va. 22102
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47. April 1979                             Flexible Datagram Protocol
  48.  
  49.                         TABLE OF CONTENTS
  50.  
  51.                                                         Page
  52.  
  53. PREFACE . . . . . . . . . . . . . . . . . . . . . . .    ii
  54.  
  55. INTRODUCTION  . . . . . . . . . . . . . . . . . . . .     1
  56.  
  57.     Motivation  . . . . . . . . . . . . . . . . . . .     1
  58.     Scope . . . . . . . . . . . . . . . . . . . . . .     1
  59.     Interfaces  . . . . . . . . . . . . . . . . . . .     2
  60.  
  61. OVERVIEW  . . . . . . . . . . . . . . . . . . . . . .     2
  62.  
  63.     Framework   . . . . . . . . . . . . . . . . . . .     2
  64.     Protocol Mechanisms . . . . . . . . . . . . . . .     2
  65.         Network Addressing  . . . . . . . . . . . . .     2
  66.         Host Addressing . . . . . . . . . . . . . . .     2
  67.         Reliability . . . . . . . . . . . . . . . . .     3
  68.         Flow Control  . . . . . . . . . . . . . . . .     3
  69.         Fragmentation . . . . . . . . . . . . . . . .     3
  70.         Higher Protocol Layer . . . . . . . . . . . .     3
  71.         Type of Service . . . . . . . . . . . . . . .     3
  72.         Options . . . . . . . . . . . . . . . . . . .     4
  73.  
  74. SPECIFICATION   . . . . . . . . . . . . . . . . . . .     5
  75.  
  76.    Header Format  . . . . . . . . . . . . . . . . . .     5
  77.  
  78. ATTRIBUTES . . . . . . . . . . . . . . . . . . . . . .    7
  79.  
  80.     Network Addressing . . . . . . . . . . . . . . . .    7
  81.     Host Addressing  . . . . . . . . . . . . . . . . .    8
  82.     Reliability  . . . . . . . . . . . . . . . . . . .    9
  83.     Flow Control . . . . . . . . . . . . . . . . . . .   10
  84.     Fragmentation  . . . . . . . . . . . . . . . . . .   11
  85.     Higher Protocol Layer  . . . . . . . . . . . . . .   12
  86.     Type of Service  . . . . . . . . . . . . . . . . .   13
  87.     Options  . . . . . . . . . . . . . . . . . . . . .   14
  88.  
  89. ADDRESSING OPERATION   . . . . . . . . . . . . . . . .   17
  90.  
  91. FLOW CONTROL OPERATION . . . . . . . . . . . . . . . .   18
  92.  
  93. FRAGMENTATION OPERATION  . . . . . . . . . . . . . . .   20
  94.  
  95. REFERENCES . . . . . . . . . . . . . . . . . . . . . .   21
  96.  
  97.  
  98.  
  99.                                                          [Page i]
  100.  
  101. Flexible Datagram Protocol                             April 1979
  102.  
  103.                              Preface
  104.  
  105. This is not a formal protocol specification.  As such  there  are
  106. descriptions that are weak and open to interpretation.  This is a
  107. working document describing the kinds of functions that  we  feel
  108. will  be  needed in a cable-bus transport level protocol.  As our
  109. implementation progresses, certain functions  may  be  done  away
  110. with completely or may be subsumed into other higher level proto-
  111. cols.  If the implementation is successful, and if there is  suf-
  112. ficient interest, a less ambiguous version will follow.
  113.  
  114.         A description of the project which will use this protocol
  115. is  contained  in  [1].   Reference 1 is recommended as a closely
  116. coupled companion to this IEN.
  117.  
  118.         The  protocol was constructed by taking pieces from other
  119. definitions.   The  Internet  Datagram  Protocol  [2]   and   the
  120. Transmission  Control  Protocol  [3]  were used as models both in
  121. terms of mechanisms and document format.  Many thanks to the ori-
  122. ginators of those documents.
  123.  
  124.                                                 Steve Holmgren
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158. [Page ii]
  159.  
  160. April 1979                             Flexible Datagram Protocol
  161.  
  162.                           Introduction
  163.  
  164.         The Flexible Datagram Protocol (FDP)  defines  a  set  of
  165. rules  to  govern  the  transport  of  blocks of data, called da-
  166. tagrams, over interconnected cable-bus networks with  binary  de-
  167. grees  of reliability, flow control, addressing, and other common
  168. transport level protocol mechanisms.  FDP  uses  variable  length
  169. datagram  headers.  Each header contains a bit-map specifying the
  170. "shape" or attributes of the remaining  portion  of  the  header.
  171. These  attributes  are groups of data fields which, if specified,
  172. cause the protocol mechanisms referred to above  to  be  invoked.
  173. If  an  attribute is not specified, default processing mechanisms
  174. will be invoked and attribute data fields are not placed  in  the
  175. header.
  176.  
  177. Motivation
  178.  
  179.         A protocol may be viewed as a collection of mechanisms to
  180. support a specific service.  Traditional mechanisms include: flow
  181. control,  addressing,  and  reliability  (e.g.  checksums, parity
  182. etc.).   Newer  mechanisms  include  datagram  fragmentation  and
  183. reassembly  to  enable their passage through "smaller-sized" net-
  184. works, and handling of a datagram security level.
  185.  
  186.         The  Flexible Datagram Protocol is motivated by a need to
  187. support a cable bus user community with widely varying  transport
  188. protocol  requirements.   The  user  community ranges from cable-
  189. based telephone users who need audio, and soon  video,  capabili-
  190. ties,  to the somewhat classic terminal-to-computer and computer-
  191. to-computer users.
  192.  
  193.         The  FDP  meets these needs by allowing a user to dynami-
  194. cally specify the mechanisms to be applied to a datagram.   If  a
  195. user  requires  a  mechanism to support a particular type of data
  196. transfer, the price is paid in terms of header overhead and  pro-
  197. cessing  cycles.  No penality is paid if a user has no need for a
  198. particular mechanism.
  199.  
  200. Scope
  201.  
  202.         The Flexible Datagram Protocol is intended to  provide  a
  203. full  range of mechanisms to support the communication of packets
  204. of data, called datagrams, between low-level nodes  of  intercon-
  205. nected  cable-busses.   This version defines the selection of the
  206. following protocol mechanisms:
  207.  
  208.                 1. network addressing,
  209.                 2. host addressing,
  210.                 3. data reliability,
  211.                 4. flow control,
  212.                 5. datagram fragmentation,
  213.                 6. higher protocol layer,
  214.                 7. type of service, and
  215.                 8. options.
  216.  
  217.                                                          [Page 1]
  218.  
  219. Flexible Datagram Protocol                             April 1979
  220.  
  221. Each of the mechanisms is described below.
  222.  
  223. Interfaces
  224.  
  225.         On  one  side, FDP interfaces to a higher level protocol;
  226. possibly a virtual circuit protocol such as Transmission  Control
  227. Protocol.   On  the  other  side  it interfaces directly with the
  228. lowest level software to transfer a datagram between itself and a
  229. cable-bus.
  230.  
  231.                             OVERVIEW
  232.  
  233.         This  section  gives an overview of the framework used to
  234. select the mechanisms to be applied to a  datagram  and  then  an
  235. overview of the operation of the mechanisms.
  236.  
  237. Framework
  238.  
  239.         The  framework consists of a bit map, called an Attribute
  240. Specification, and a pre-defined sequence in which a fixed-format
  241. group  of  data  fields,  called  attributes, are processed.  The
  242. Attribute Specification defines whether  an  attribute  has  been
  243. placed  in  the  header.   If the specification indicates that an
  244. attribute is in the header, the appropriate number of  bytes  are
  245. handed  to  the  cooresponding protocol mechanism for processing.
  246. If an attribute is not in the header,  default  processing  takes
  247. place.   The  next  attribute in the pre-defined sequence is then
  248. checked.  This cycle continues until the Attribute  Specification
  249. is exhausted.
  250.  
  251. Protocol Mechanisms
  252.  
  253.         Attributes  are  processed  in the same sequence in which
  254. they are described in this section.
  255.  
  256.         Network  Addressing.   The  Network  Address Attribute is
  257. provided to allow users to address sites on a remote network  via
  258. a  gateway  or  series of gateways which interconnect two or more
  259. networks.
  260.  
  261.         The  Network  Addressing  Attribute  fields  specify  the
  262. source and destination networks  for  the  datagram.   Since  the
  263. cable-bus  is broadcast in nature, all gateways to other networks
  264. will "see" any request for transmission to a remote network.  The
  265. gateway(s)  to  the  specified  network  is (are) responsible for
  266. accepting the datagram, processing  the  Attribute  specification
  267. and  performing  the appropriate routing of the remaining portion
  268. of the datagram to the remote network.
  269.  
  270.         Host Addressing.  The Host Addressing Attribute is neces-
  271. sarily provided to allow users to address datagrams  to  specific
  272. destinations.
  273.  
  274.         The Host Addressing Attribute fields specify  the  source
  275.  
  276. [Page 2]
  277.  
  278. April 1979                             Flexible Datagram Protocol
  279.  
  280. and destination host numbers for the datagram.
  281.  
  282.         Reliability.  The Reliability Attribute  is  provided  to
  283. insure that datagrams are delivered without enroute damage.
  284.  
  285.         The Reliability Attribute has  a  checksum  field  and  a
  286. length  field.   The checksum is the complement of the sum of the
  287. datagram octets.  The length field specifies the  number  of  all
  288. octets in the datagram.
  289.  
  290.         Flow Control.  The Flow Control Attribute  allows  a  re-
  291. ceiver  to  control the speed at which a transmitter may send da-
  292. tagrams.  It uses a sliding window  acknowledgement  strategy  to
  293. acknowledge previously received datagrams and to detect duplicate
  294. and out-of-sequence datagrams.
  295.  
  296.         Each  flow controlled datagram contains a sequence number
  297. ordering the datagram in relation  to  previous  and  future  da-
  298. tagrams,  an acknowledgement field acknowledging datagrams previ-
  299. ously received by the transmitter, and a window field  specifying
  300. a range of acceptable per datagram sequence numbers.
  301.  
  302.         Fragmentation.  The Fragmentation Attribute  is  included
  303. to allow the transmission of large (greater than 256 octets) mes-
  304. sages as a series of datagrams which are reassembled at the  des-
  305. tination  before  delivery to a user.  Further, it enables a more
  306. direct interconnection of cable bus  systems  with  "small-sized"
  307. networks.
  308.  
  309.         The Fragmentation Attribute contains  a  sequence  number
  310. defining  the  relationship between previous and future fragments
  311. of a larger message, a message id relating fragments  of  a  mes-
  312. sage,  a  flags  field controlling further fragmentation and last
  313. fragment indications, and a  life  time  specification  which  is
  314. decremented as the datagram passes through different internetwork
  315. gateways.  If the life time field reaches zero, the  datagram  is
  316. assumed  to be looping through a sequence of gateways and is dis-
  317. carded.
  318.  
  319.         Higher  Protocol Layer.  The Higher Protocol Layer Attri-
  320. bute specifies the next layer of protocol which is to receive the
  321. datagram.   It  is  included  to  allow the use of FDP by several
  322. higher level protocol implementations within the same  host.   By
  323. specifying the next protocol layer within a lower layer, the for-
  324. mat of the headers of the higher level  protocols  are  not  res-
  325. tricted  to a common preamble which would be required to demulti-
  326. plex messages.
  327.  
  328.         Type  of  Service.   The Type of Service Attribute is in-
  329. cluded to allow the user to give some indication of the  priority
  330. which  is  to  be applied to a datagram.  Initially, the priority
  331. may be restricted to linkage of datagrams to the front of  inter-
  332. nal queues so that immediate attention is given to their process-
  333. ing.  Later, this may be expanded to  the  notion  of  preemptive
  334.  
  335.                                                          [Page 3]
  336.  
  337. Flexible Datagram Protocol                             April 1979
  338.  
  339. allocation  of  resources,  and  selection  of higher speed, less
  340. congested transmission channels.
  341.  
  342.         The Type of Service Attribute contains a field to specify
  343. the priority of the message (lowest to highest), and a  field  to
  344. specify  the  requested  speed  of  the message (again highest to
  345. lowest) within the priority level.
  346.  
  347.         Options.   The  Options  Attribute provides control func-
  348. tions needed or useful in some  situations  but  unnecessary  for
  349. routine  communications.   It is also provided to support experi-
  350. mental mechanisms that at some point may be elevated to Attribute
  351. status.
  352.  
  353.         The Options Attribute  includes  provisions  for  special
  354. routing, error messages, protocol version specification, datagram
  355. security level, and special low-level signals such as reset.
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. [Page 4]
  395.  
  396. April 1979                             Flexible Datagram Protocol
  397.  
  398.                           SPECIFICATION
  399.  
  400. Header Format
  401.  
  402.         The  header  contains an Attribute Specification followed
  403. by a variable number of attributes.  Each attribute is a group of
  404. data  fields.   This is the format of a header specifying all at-
  405. tributes.  The brackets  attempt  to  delineate  attribute  boun-
  406. daries.
  407.  
  408.                        1                   2                   3
  409.    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  410.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  411.   !  Att. Spec.   !   Att. Spec.  ! [ Dest. Net.  !   Src. Net ]  !
  412.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  413.   !  [        Dest.  Host         !           Src. Host        ]  !
  414.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  415.   !  [  Chksum    !      Len    ] ! [     Ack     !     Window    !
  416.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.   !            Seq. Num.        ] ! [    Flags    !   Life Time   !
  418.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.   !         Frag. Offset          !             Msg. Id        ]  !
  420.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.   ![ Nxt. Proto. ]![Type of Serv.]! [         Options          ]  !
  422.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  423.   !                            Data                               !
  424.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425.  
  426.         Note that each tick mark corresponds to a bit position.
  427.  
  428.  
  429. Attribute Specification:  8 bits (replicated)
  430.  
  431.         Each bit in the Attribute Specification determines wheth-
  432. er an attribute is present in the header.  The order in which the
  433. attributes  are processed corresponds to the bit positions in the
  434. Attribute Specification.  The order in which the attribute fields
  435. are stored in the header is shown in the figure above.  Note that
  436. the Attribute Specification is repeated in  the  header  so  that
  437. damage  to it may be detected.  If a damaged Attribute Specifica-
  438. tion is detected, the datagram is discarded.
  439.  
  440.         The  figure below shows the correspondence between Attri-
  441. bute Specification bits and attributes.
  442.  
  443.          0 1 2 3 4 5 6 7
  444.         +-+-+-+-+-+-+-+-+
  445.         !N H R F F P T O!
  446.         !A A E L R R O P!
  447.         !D D L O G O S T!
  448.         +-+-+-+-+-+-+-+-+
  449.  
  450.         NAD: Network Addressing         FRG: Fragmentation
  451.         HAD: Host Addressing            PRO: Next Level Protocol
  452.  
  453.                                                          [Page 5]
  454.  
  455. Flexible Datagram Protocol                             April 1979
  456.  
  457.         REL: Reliability                TOS: Type of Service
  458.         FLO: Flow Control               OPT: Options
  459.  
  460. If  a  bit  is  on  in the Attribute Specification, the attribute
  461. fields will be found in the header.  If a bit is off, the  attri-
  462. bute fields are not present in the header.  The following example
  463. shows a header with Host Address and Reliability Attributes.  The
  464. brackets deliniate attribute boundaries.
  465.  
  466.                         1                   2                   3
  467.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  468.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  469.    !0 1 1 0 0 0 0 0!0 1 1 0 0 0 0 0! [        Dest Host            !
  470.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  471.    !          Src. Host          ] ! [   Chksum    !      Len    ] !
  472.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  473.    !            Data                               !
  474.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512. [Page 6]
  513.  
  514. April 1979                             Flexible Datagram Protocol
  515.  
  516.                            ATTRIBUTES
  517.  
  518. Network Addressing:  (Bit 0)
  519.  
  520.         The Network Addressing Attribute has a Destination and  a
  521. Source Network field.
  522.  
  523.         If not specified the datagram is not routed  outside  the
  524. local network.  See Addressing Operation below.
  525.  
  526.         Dest. Net. (Destination Network):  8 bits
  527.             Contains  the  number  of  the network to
  528.             which the datagram is to be routed.
  529.  
  530.         Src. Net. (Source Network):  8 bits
  531.             Contains the number of the  network  from
  532.             which the datagram originated.
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.                                                          [Page 7]
  572.  
  573. Flexible Datagram Protocol                             April 1979
  574.  
  575. Host Addressing:  (Bit 1)
  576.  
  577.         The  Host  Addressing  Attribute  has  a  Destination and
  578. Source Host field.
  579.  
  580.         If  not specified, the datagram is a broadcast message to
  581. all hosts.  See Addressing Operation below.
  582.  
  583.         Dest. Host.  (Destination Host):  16 bits
  584.             Contains the number of the host to  which
  585.             the datagram is to be routed.
  586.  
  587.         Src. Host (Source Host):  16 bits
  588.             Contains  the  number  of  the host which
  589.             originated the datagram.
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630. [Page 8]
  631.  
  632. April 1979                             Flexible Datagram Protocol
  633.  
  634. Reliability: (Bit 2)
  635.  
  636.         The Reliability  Attribute  contains  a  checksum  and  a
  637. length field.
  638.  
  639.         If not specified, the datagram is assumed to be undamaged
  640. and its length is obtained from the hardware interface.
  641.  
  642.         Chksum (Checksum):  8 bits
  643.             The  Checksum  field  contains  the one's
  644.             complement of the one's  complement  byte
  645.             sum  of the datagram.  The Checksum field
  646.             is set to  zero  while  the  checksum  is
  647.             being computed.
  648.  
  649.         Len. (Length):  8 bits
  650.             The  Length field specifies the number of
  651.             octets  in  the  datagram.   This   field
  652.             counts all header and data octets.
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.                                                          [Page 9]
  690.  
  691. Flexible Datagram Protocol                             April 1979
  692.  
  693. Flow Control: (Bit 3)
  694.  
  695.         The  Flow  Control  Attribute contains an Acknowledgement
  696. field, a Window field, and a Sequence Number field.
  697.  
  698.         If  not  specified,  the  datagram is not subject to flow
  699. control considerations.  See Flow Control Operation below.
  700.  
  701.         Ack. (Acknowledgement):  8 bits
  702.             The  Acknowledgement  field  contains   a
  703.             sequence  number  greater  than  or equal
  704.             (cyclically) to the sequence  numbers  of
  705.             all successfully received datagrams.
  706.  
  707.         Window: 8 bits
  708.             The  Window  field contains the number of
  709.             datagrams beyond the sequence  number  in
  710.             the   Acknowledgement   field  which  the
  711.             sender of  the  datagram  is  willing  to
  712.             accept.
  713.  
  714.         Seq. Num. (Sequence Number): 16 bits
  715.             The  Sequence  Number  field contains the
  716.             sequence number of the datagram.
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748. [Page 10]
  749.  
  750. April 1979                             Flexible Datagram Protocol
  751.  
  752. Fragmentation:  (bit 4)
  753.  
  754.         The Fragmentation Attribute contains  a  Flags  field,  a
  755. Life  Time  field,  a  Fragment Offset field, and a Message iden-
  756. tifer.
  757.  
  758.         If the Fragmentation Attribute is not specified, gateways
  759. are free to fragment the datagram into smaller  messages  if  re-
  760. quired  by  the destination network.  See Fragmentation Operation
  761. below.
  762.  
  763.         Flags:  8 bits
  764.             Various Control Flags.
  765.                  0 1 2 3 4 5 6 7
  766.                 +-+-+-+-+-+-+-+-+
  767.                 !0 D M 0 0 0 0 0!
  768.                 !0 F F 0 0 0 0 0!
  769.                 +-+-+-+-+-+-+-+-+
  770.  
  771.                 Bit 0:  reserved, must be zero.
  772.                 Bit 1:  Don't Fragment This Datagram (DF).
  773.                 Bit 2:  More Fragments Field (MF).
  774.                 Bit 3:  Unused, must be zero.
  775.                 Bit 4:  Unused, must be zero.
  776.                 Bit 5:  Unused, must be zero.
  777.                 Bit 6:  Unused, must be zero.
  778.                 Bit 7:  Unused, must be zero.
  779.  
  780.         Life Time:  8 bits
  781.             This field is decremented  for  each  hop
  782.             taken  through  the  internetwork system.
  783.             If it decrements to zero, the datagram is
  784.             presumed  to  be  in an internetwork loop
  785.             and should be discarded.
  786.  
  787.         Frag. Offset (Fragmentation Offset):  16 bits
  788.             This field relates the datagram to previ-
  789.             ous  and future fragments.  Each fragment
  790.             datagram  is  given  a  sequence  number.
  791.             This  field  orders the fragment in rela-
  792.             tion to other fragments.
  793.  
  794.         Msg. Id. (Message Identifer): 16 bits
  795.             This field is an arbitrary identifer  for
  796.             the  message  that  was fragmented.  Each
  797.             message fragment contains  the  identifer
  798.             to  be used as an aid in reassembling the
  799.             fragments of the message.
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.                                                         [Page 11]
  808.  
  809. Flexible Datagram Protocol                             April 1979
  810.  
  811. Next Higher Level Protocol:  (bit 5)
  812.  
  813.         This attribute contains the Next Protocol field.
  814.  
  815.         If this attribute is not specified, a default higher lev-
  816. el protocol receives the datagram.
  817.  
  818.         Nxt. Proto. (Next Protocol): 8 bits
  819.             This field contains an identifier of  the
  820.             next  higher  level  protocol which is to
  821.             receive that contents of the data portion
  822.             of the datagram.
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866. [Page 12]
  867.  
  868. April 1979                             Flexible Datagram Protocol
  869.  
  870. Type of Service:  (bit 6)
  871.  
  872.         This  attribute contains the Type of Service field.  This
  873. field, if present, defines the priority and  relative  speed  re-
  874. quirements  within the priority which the sender wishes to attach
  875. to the datagram.
  876.  
  877.         If  not  specified,  no  special handling is given to the
  878. datagram.
  879.  
  880.         Type of Serv. (Type of Service):  8 bits
  881.             The Type of Service  field  contains  two
  882.             sub-fields  with  define  the priority of
  883.             the datagram and the speed which is to be
  884.             applied to the datagram.
  885.  
  886.                     0 1 2 3 4 5 6 7
  887.                    +-+-+-+-+-+-+-+-+
  888.                    !   Pri   ! Spd !
  889.                    +-+-+-+-+-+-+-+-+
  890.  
  891.                 Priority                Speed
  892.                 0  - Lowest             0 - Slowest
  893.                 31 - Highest            7 - Fastest
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.                                                         [Page 13]
  926.  
  927. Flexible Datagram Protocol                             April 1979
  928.  
  929. Options: (bit 7)
  930.  
  931.         This attribute contains a variable number of fields.  The
  932. format is an option-type octet, an option-length octet,  and  the
  933. actual  option-data  octets.   There are two special case options
  934. which have only the option-type octet (End of  Options  List  and
  935. Nop).
  936.  
  937.         The option-length octet includes  the  option-type  octet
  938. and  the  option-length  octet  in  the octet count of the option
  939. length.
  940.  
  941.         The  option-type  octet  can  be  viewed  as having three
  942. fields:
  943.  
  944.                 1 bit   reserved, must be zero
  945.                 2 bits  option class
  946.                 5 bits  option number
  947.  
  948. The option classes are:
  949.  
  950.                 0 = control
  951.                 1 = internet error
  952.                 2 = experimental debugging and measurement
  953.                 3 = reserved for future use
  954.  
  955.         If  not  specified,  no  special option processing is re-
  956. quested.
  957.  
  958. The following options are defined:
  959.  
  960.         Class  Number  Length  Description
  961.           0      0       -     End of Option List.
  962.           0      1       -     No Operation
  963.           0      2       4     S/P/T. Security, Precidence, TCC
  964.           0      3       var.  Source Routine.
  965.           0     31       4     Reset
  966.           0     30       var.  Status
  967.           1      1       var.  General Error Report.
  968.           2      4       var.  Internet Timestamp
  969.           2      5       var.  Satellite Timestamp
  970.  
  971.  
  972. Specific Option Definitions
  973.  
  974.         End of Option List.  This option  indicates  the  end  of
  975. option  list.   It  is  always  used to terminate the list of all
  976. options.
  977.  
  978.         +--------+
  979.         !00000000!
  980.         +--------+
  981.  
  982.         No Operation.  This option may be used between options to
  983.  
  984. [Page 14]
  985.  
  986. April 1979                             Flexible Datagram Protocol
  987.  
  988. align the beginning of a subsequent option on a 32 bit boundary.
  989.  
  990.         +--------+
  991.         !00000001!
  992.         +--------+
  993.  
  994.         S/P/T.   This  option provides a way for AUTODIN II hosts
  995. to send security, precedence, and TCC (closed user groups) param-
  996. eters  through  networks  whose transport leader does not contain
  997. fields for this information.
  998.  
  999.         +--------+--------+--------+--------+
  1000.         !00000010!00000100!Prec!Sec!  TCC   !
  1001.         +--------+--------+--------+--------+
  1002.  
  1003.         Precedence: 4 bits
  1004.                 Specifies one of 16 levels of precedence.
  1005.  
  1006.         Security: 4 bits
  1007.                 Specifies one of 16 levels of security.
  1008.  
  1009.         Transmission Control Code (TCC): 8 bits
  1010.                 Provides a means to compartmentalize traffic
  1011.                 and define controlled communities of interest
  1012.                 among subscribers.
  1013.  
  1014.         Source Routing.  The source  routing  option  provides  a
  1015. means  for the source of a datagram to supply routing information
  1016. to be used by gateways in forwarding the datagram to the destina-
  1017. tion.
  1018.  
  1019.         A source route is composed of a series  of  internet  ad-
  1020. dresses.   The  pointer  is  initially  zero, which indicates the
  1021. first octet of the source route.  The segment is  routed  to  the
  1022. address  in  the  source  route indicated by the pointer.  At the
  1023. internet module the pointer is advanced to the  next  address  in
  1024. the  source  route.   This routing and pointer advancement is re-
  1025. peated until the source address is exhausted.  At that point, the
  1026. destination  may  have  been reached, if not, the protocol module
  1027. must attempt to route the packet to the destination in the desti-
  1028. nation address field by the ordinary routing procedure.
  1029.  
  1030.         +--------+---------+--------+--------+-----/ /-----+
  1031.         !00000011! length  ! pointer!  source route        !
  1032.         +--------+---------+--------+-------------/ /------+
  1033.  
  1034.         Reset.   The  reset  option allows a host on a network to
  1035. signal other hosts that its network operations have been restart-
  1036. ed.  The data field contains the address of the restarted host.
  1037.  
  1038.         +--------+--------+--------+--------+
  1039.         !00011111!00000100!  Host Address   !
  1040.         +--------+--------+--------+--------+
  1041.  
  1042.  
  1043.                                                         [Page 15]
  1044.  
  1045. Flexible Datagram Protocol                             April 1979
  1046.  
  1047.         Status.   The  status  option  allows  a host to transmit
  1048. status information to a remote host.  The conditions for  elicit-
  1049. ing  the  information and the content of the data fields are net-
  1050. work dependent.
  1051.  
  1052.         +--------+--------+---------+--------/ /------+
  1053.         !00011110! length !   Status Info             !
  1054.         +--------+--------+---------+-------/ /-------+
  1055.  
  1056.         General Error Report.  The general error report  is  used
  1057. to  report  an  error detected in the processing of a datagram to
  1058. the originator of the datagram.  The  "err  code"  indicates  the
  1059. type of error detected and the "id" is copied from the message id
  1060. field of the datagram, if it exists.  Additional octets of  error
  1061. information may be present depending on the error code.
  1062.  
  1063.         Err Code:
  1064.             0  -  Undetermined Error Used when no in-
  1065.             formation is available about the type  of
  1066.             error  or  the  error does not fit in any
  1067.             defined class.
  1068.  
  1069.             No  error codes for specific classes have
  1070.             been defined.
  1071.  
  1072.         +--------+--------+--------+--------+----/ /------+
  1073.         !00100001! length !err code!   id   !             !
  1074.         +--------+--------+--------+--------+-----/ /-----+
  1075.  
  1076.         Internet Timestamp.  No information is available  on  the
  1077. specific format of Timestamps.
  1078.  
  1079.         +--------+--------+--------+--------+-----/ /-----+
  1080.         !01000100! length !                               !
  1081.         +--------+--------+--------+--------+----/ /------+
  1082.  
  1083.         Satellite  Timestamp.  No information is available on the
  1084. specific format of Timestamps.
  1085.  
  1086.         +--------+--------+---------+--------+---/ /-----+
  1087.         !01000101! length !                              !
  1088.         +--------+--------+---------+--------+---/ /-----+
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102. [Page 16]
  1103.  
  1104. April 1979                             Flexible Datagram Protocol
  1105.  
  1106.                       Addressing Operation
  1107.  
  1108.         A  distinction  is  made  between  names,  addresses, and
  1109. routes [4].  A name indicates what we seek.  An address indicates
  1110. where  it  is.  A route indicates how to get there.  The Flexible
  1111. Datagram Protocol deals only with addresses.  It is the  task  of
  1112. higher  level  protocols  to  make  the mapping from names to ad-
  1113. dresses.  It is the task of lower level procedures (i.e. internet
  1114. gateways) to make the mapping from addresses to routes.
  1115.  
  1116.         When the Network Address Attribute is specified, the net-
  1117. work fields have values obtained from reference [5].  When a mes-
  1118. sage is transmitted to the cable-bus, all internet gateways watch
  1119. for messages with destination networks to which they have access.
  1120. If a match is found, the remaining attributes of the  header  are
  1121. processed  according  to  specified  convention.  The datagram is
  1122. then passed along the route to the remote network after  possible
  1123. fragmentation.
  1124.  
  1125.         When the Host Address Attribute is specified, hosts  com-
  1126. pare  the  destination host field with their address.  If a match
  1127. is found, and  the  destination  network  number  (if  specified)
  1128. matches  the local network number, the host processes the remain-
  1129. ing Attributes in the header of the datagram and passes the  data
  1130. portion of the datagram to the next higher level protocol.
  1131.  
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.                                                         [Page 17]
  1162.  
  1163. Flexible Datagram Protocol                             April 1979
  1164.  
  1165.                      Flow Control Operation
  1166.  
  1167.         Flow  control  regulates  the transfer of data.  Each re-
  1168. ceiver controls the amount of data a transmitter may send.   Each
  1169. receiver  can  dynamically  update  this  control without loss or
  1170. duplication of data.
  1171.  
  1172.         Each  datagram  containing  the Flow Control Attribute is
  1173. assigned a sequence number.  The sequence numbers range from 0 to
  1174. 65535  and  are  used  cyclically; i.e. 0 follows 65535.  The se-
  1175. quence number for each datagram is placed in the header  of  each
  1176. outgoing  datagram  containing  the  Flow Control Attribute.  The
  1177. first sequence number used is zero.
  1178.  
  1179.         The  Ack  field  contains the sequence number of the last
  1180. datagram accepted by the transmitter.  The receiver can  consider
  1181. all  sequence  numbers  (cyclically)  less  than  or equal to the
  1182. number in the Ack field to have been received by  the  other  end
  1183. and can free buffers accordingly.
  1184.  
  1185.         The Window field contains the number of datagrams, beyond
  1186. that  denoted  by  the  Ack  field,  the transmitter is currently
  1187. prepared to accept.  The datagrams  will  have  sequence  numbers
  1188. (Ack + 1) through (Ack + Window) cyclically calculated.  A window
  1189. value of zero indicates that the transmitter is not  prepared  to
  1190. accept  any  datagrams  until further notice.  This does not mean
  1191. that a transmitter may not send a datagram.  It  means  that  re-
  1192. transmission intervals should be increased significantly.
  1193.  
  1194.         The sending of a datagram with a non-zero window does not
  1195. irrevocably  commit  a  transmitter  to accept that number of da-
  1196. tagrams.  Changing conditions may cause an untimely reduction  in
  1197. the  window  size.  These conditions may prevail at the same time
  1198. other transmitters are sending datagrams  (for  which  they  were
  1199. given  a  non-zero  window)  to the afflicted host.  Sequences of
  1200. this kind can generate duplicate and discarded datagrams.
  1201.  
  1202.         A  receiver  must be able to detect and discard duplicate
  1203. datagrams.  In order for duplicate detection to be possible,  the
  1204. Window  field  must not contain a value greater than half the se-
  1205. quence number space (i.e. 32768) and no more than 32768 datagrams
  1206. may  be  unacknowledged at any time.  A receiver may identify du-
  1207. plicate datagrams as those with sequence numbers in the range
  1208.  
  1209.     ((last acknowledged) - 32767) through (last acknowledged)
  1210.  
  1211. A receiver should discard any datagrams with sequence numbers  in
  1212. this range.
  1213.  
  1214.         Sending a window size greater than 32768  is  prohibited.
  1215. Receiving  a window size greater than 32768 should be adjusted to
  1216. 32768.
  1217.  
  1218.         Certain  combinations  of events can generate the receipt
  1219.  
  1220. [Page 18]
  1221.  
  1222. April 1979                             Flexible Datagram Protocol
  1223.  
  1224. of datagrams out of sequence.  A  receiver  may  discard  out-of-
  1225. sequence  datagrams  or it may save them for later insertion into
  1226. the proper sequence.
  1227.  
  1228.         It is possible for datagrams to arrive for which a window
  1229. does not currently exist.   A  receiver  may  discard  these  da-
  1230. tagrams.
  1231.  
  1232.         A transmitter should be aware  of  these  situations  and
  1233. have  sufficient mechanisms to retransmit a datagram after a rea-
  1234. sonable time has elapsed.  Various strategies for defining  "rea-
  1235. sonable" are under study.
  1236.  
  1237.         The simplest strategy a receiver can employ is to  accept
  1238. only  the next datagram in sequence and discard all others.  This
  1239. works if the receiver employs a somewhat linear window policy.
  1240.  
  1241.         Acknowledgements  should  be  sent  as  soon as possible.
  1242. They may be carried by datagrams flowing the other  way.   If  no
  1243. datagram  is available for carrying the response after a "reason-
  1244. able" time a datagram containing appropriate  Address  Attributes
  1245. and  the Flow Control Attribute should be artifically constructed
  1246. and transmitted.  It may  be  reasonable  to  employ  a  time-out
  1247. mechanism  controlling  generation  of "acknowledgement only" da-
  1248. tagrams.
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.                                                         [Page 19]
  1280.  
  1281. Flexible Datagram Protocol                             April 1979
  1282.  
  1283.                      Fragmentation Operation
  1284.  
  1285.         Fragmentation of a datagram may be necessary when it ori-
  1286. ginates in a remote network that allows a large datagram size and
  1287. must traverse the local  network  which  limits  datagrams  to  a
  1288. smaller size.
  1289.  
  1290.         The Message Identification field is  used  together  with
  1291. the  source  and  destination  address (if present), and the Next
  1292. Protocol field (if present) to identify fragments for reassembly.
  1293.  
  1294.         The  More  Fragments flag bit (MF) is set if the datagram
  1295. is not the last fragment.  The Fragment Offset  field  identifies
  1296. the  fragment  number  relative  to the beginning of the original
  1297. unfragmented datagram; zero is the first fragment, one the second
  1298. and so on.
  1299.  
  1300.         When fragmentation  occurs,  options  are  generally  not
  1301. copied,  but  remain with the first fragment.  Some options, such
  1302. as source routing, must be copied.
  1303.  
  1304.         The  fields  which  may  be affected by fragmentation in-
  1305. clude:
  1306.  
  1307.                 (1)  options field
  1308.                 (2)  more fragments flag
  1309.                 (3)  fragment offset
  1310.                 (4)  checksum (if present)
  1311.  
  1312.         If  the Don't Fragment flag (DF) bit is set then fragmen-
  1313. tation of the datagram is not permitted, although it may be  dis-
  1314. carded.   This  is  used  where  the receiving host does not have
  1315. resources to reassemble fragments.
  1316.  
  1317.         The  choice of Message Identifier for a datagram is based
  1318. on the need to provide a way to uniquely identify  the  fragments
  1319. of  a  particular datagram.  The protocol module assembling frag-
  1320. ments judges fragments to belong ot the  same  datagram  if  they
  1321. have the same source, destination, Next Higher Level Protocol (if
  1322. present), and Message Identifier.  Thus, the sender  must  choose
  1323. the  Identifier to be unique for this source and destination pair
  1324. and protocol over the time the datagram (or any fragment  of  it)
  1325. could be alive in the internetwork.
  1326.  
  1327.         It is appropriate for  some  higher  level  protocols  to
  1328. choose  the  identifier.  For example, TCP modules may retransmit
  1329. an identical TCP segment, and the probability for correct  recep-
  1330. tion  would  be  enhanced  if the retransmission carried the same
  1331. identifier as the original transmission since fragments of either
  1332. datagram could be used to reconstruct a correct TCP segment.
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338. [Page 20]
  1339.  
  1340. April 1979                             Flexible Datagram Protocol
  1341.  
  1342.                            REFERENCES
  1343.  
  1344. [1]     Skelton, A.P.,  Holmgren, S.F., "The MITRE
  1345.         Cablenet Project", IEN 96, April 1979
  1346.  
  1347. [2]     Information Sciences Institute, "Internet Datagram Protocol",
  1348.         Version 4, IEN 80, February 1979
  1349.  
  1350. [3]     Information Sciences Institute, "Transmission Control Protocol",
  1351.         Version 4, IEN 81, February 1979
  1352.  
  1353. [4]     Shoch, J., "A Note On Inter-Network Naming, Addressing, and
  1354.         Routing," Xerox Palo Alto Research Center, IEN 19, January 1978.
  1355.  
  1356. [5]     Postel, J., "Assigned Numbers," RFC 750, NIC 45500,
  1357.         26 September 1978.
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.                                                         [Page 21]
  1398.